digital trust system, computer readable and computerized method

专利摘要:
this disclosure involves systems and methods for authenticating identity across multiple institutions using a trusted mobile device as a proxy for a user login. in one example, operations include identifying a request to trust a specific user associated with a first entity on a digital id network. a set of personally identifiable information (pii) associated with the user is obtained through the first entity and an identity verification (idv) / fraud risk analysis is carried out. in response to satisfying the analysis, instructions are passed on to the user to verify identity through a trusted mobile app on an associated mobile device. after verification, the mobile device is linked to the user within the digital id network, along with a digital id associated with the specific user. the digital id can be used by other entities registered in the digital id network to authenticate the user.
公开号:BR112019017075A2
申请号:R112019017075
申请日:2018-02-16
公开日:2020-04-28
发明作者:Pigg Esther；R Khanna Gaurav；Cano Helcio；Romain Marty；Bijlani Ravindra；Huffman Richard；Michaelson Richard；Harris Rob；Salem Shriram；Van Zyl Vivian
申请人:Equifax Inc；Fidelity Information Services Llc；
IPC主号:

专利说明:

“DIGITAL CONFIDENCE SYSTEM, MEDIA LEGIBLE BY COMPUTER AND COMPUTERIZED METHOD”
Priority Claim [001] This application claims priority to US patent application 62 / 460,611 filed on February 17, 2017, the entire contents of which is incorporated into this application as a reference.
Technical Field [002] [0001] This disclosure relates to computer systems and computer-implemented methods for identity authentication for use through financial institutions based on the device profile and biometrics to allow a mobile device to be used as a proxy for user authentication with a high credential trust.
[003] Consumers and companies have adopted the use of online digital interaction channels in financial, commercial and transaction related activities. As a result, accurate and secure authentication and the protection of your personally identifiable personal information (Pll) is a critical task for all financial institutions and retailers. However, current digital authentication methods have significant weaknesses and pose security threats that put individuals, businesses and government entities at risk.
[004] In addition to the risks of intercepting this information, banks, financial institutions and other entities encountered resistance during the process of authenticating users through cell phones and other computing devices, being one of the main causes of abandonment of transactions or processes . In addition, as no holistic view of specific consumer activity is available, fraud losses may occur between different institutions without sharing information or transactional context. In addition, the increased risks and costs are
Petition 870190079542, of 16/08/2019, p. 75/148
2/61 associated with redundant and / or manual data capture, including captures associated with various registrations and logins for different websites, applications and other online entry points.
[005] For consumers, resistance during the authentication process can be bothersome and frustrating. Users may be afraid to repeatedly share personal information on various websites and with various applications. In addition, fatigue arises from managing multiple passwords as the basis for authenticating different systems. Alternatively, using the same password across multiple systems increases the chance that a single interception could result in catastrophic access to account information by offenders.
Brief Description of the Invention [006] The present disclosure involves systems, software and methods implemented on a computer for identity authentication through various financial institutions with the use of a single trusted mobile device as a proxy for a user login, although allowing a high level of confidence in authentication processes based on the trusted mobile device and an assessment of existing institutional knowledge in relation to the user and predictive analysis to verify the need for authentications and identity for additional checks and authorizations. In one example, system operations include identifying a request to trust a specific user, the specific user associated with a first trust with a first entity, the first entity associated with the digital ID network. A set of personally identifiable information (P11) associated with the specific user is obtained through the first entity and an identity verification (IDV) and analysis of the user's fraud risk assessment is carried out based on the set of Pll obtained. In response to satisfying the IDV fraud risk assessment analysis, the instructions are
Petition 870190079542, of 16/08/2019, p. 76/148
3/61 transmitted to the specific user to verify the identity of the specific user through a trusted mobile application installed on a mobile device associated with the specific user. In response to verifying the identity of the specific user through the trusted mobile application installed on the mobile device, the mobile device is linked to the specific user within the digital ID network, where the mobile device is associated with a unique set of device information and the unique set of device information is incorporated into a generated digital ID associated with the specific user, where the generated digital ID is available for use by a plurality of entities registered on the digital ID network for authentication of the specific user.
[007] In some cases, the generated digital ID associated with the specific user comprises a unique key created to associate with the Pll of the specific user, where the mobile device has associated itself with the specific user and activities associated with the user.
[008] In some cases, in response to satisfying the IDV and the fraud risk assessment analysis, a unique code is generated associated with the specific user, and the transmission of instructions to the specific user to verify the identity of the specific user through the Trusted mobile application may include transmitting the generated unique code to a first entity interface with instructions for the specific user, where the identity of the specific user is verified through the trusted mobile application by verifying the unique code transmitted with instructions for the specific user. In such cases, generating the unique code may include generating an image that encodes the unique code associated with the specific user, and transmitting the unique code to the first entity's interface may include transmitting the generated image to the first entity's interface, where the instructions for the specific user to verify the identity of the specific user through the
Petition 870190079542, of 16/08/2019, p. 77/148
4/61 trusted mobile app includes instructions for capturing the image transmitted via the trusted mobile app. Verifying the identity of the specific user may include confirming that the image captured by the trusted mobile application matches the generated image that encodes the unique code associated with the specific user.
[009] In some cases, the first trust relationship between the first entity and the specific user is based on a predefined record and authentication of the specific user by the first entity.
[010] In some cases, the fraud risk assessment of the specific user includes at least one among a knowledge-based authentication, a cross-channel comparison, an out-of-band authentication, a known fraud exchange assessment, an analysis of the PII usage speed, an analysis of the transaction speed for the specific user, an analysis of transaction data, a biometric analysis, a comparison of the specific user's Pll against a set of known Pll associated with a risk of fraud and a device reputation analysis.
[011] In some cases, each entity of the plurality of entities is associated with a set of entity-specific authentication rules, each set of entity-specific authentication rules identifies a set of transactions for a specific entity and identifies an authentication level required by users associated with transactions. In these cases, at least some of the transactions for a specific entity require at least one additional first authentication operation for users associated with those transactions, where at least one additional first authentication operation comprises a first authentication request to be transmitted from of the digital trust system for a specific mobile device previously linked to the digital ID associated with the transaction
Petition 870190079542, of 16/08/2019, p. 78/148
Specific 5/61. The digital trust system is still configured to transmit the first authentication request to the trusted mobile application installed on the specific mobile device, where the first authentication request is submitted through the trusted mobile application.
[012] In some of these cases, the first request for additional authentication may comprise a request for biometric entry of the user associated with the digital ID via the trusted mobile application. Alternatively or in addition, the first additional authentication request comprises a request for a response through user input for an authentication challenge.
[013] In some cases, where the first authentication request is required, operations may still include receiving a response to the first authentication request transmitted from the trusted mobile application installed on the specific mobile device and validating the response received. In response to a valid response to the first authentication request, the transaction can be authorized, although transaction authorization may be denied in response to an invalid response to the first authentication request. In some cases, a fraud detection assessment is performed for each requested transaction associated with the digital ID, where the fraud detection assessment is performed for each user's transaction request when associated with the digital ID.
[014] In such cases, in response to a potential fraud detection based on the fraud detection assessment, at least a second additional authentication request may be made, in which at least a second additional authentication request comprises a second request for authentication. authentication to be transmitted from the digital trust system to a specific mobile device previously linked to the digital ID associated with the specific transaction, where the digital trust system is
Petition 870190079542, of 16/08/2019, p. 79/148
6/61 configured to transmit the second authentication request to the trusted mobile application installed on the specific mobile device, the second authentication request is presented through the trusted mobile application. At least a second additional authentication request associated with the detection of potential fraud can be made without a determination that at least one first additional authentication request is required.
[015] Although generally described as software implemented on a computer embedded in a tangible medium that processes and transforms the respective data, some or all aspects may be methods implemented on a computer or even included in the respective systems or other devices to carry out this described functionality. Details of these and other aspects and achievements of the present disclosure are presented in the attached Figures and in the description below. Other characteristics, objects and advantages of the disclosure will be evident from the description and figures, and from the claims.
Description of the Figures [016] Figure 1 is a block diagram illustrating an example system for implementing a digital ID network across a plurality of consumers and customers.
[017] Figure 2 is an example diagram of a simplified system for providing a digital ID network.
[018] Figure 3 is a flow chart of an example registration operation from the perspective of the partnership system.
[019] Figure 4 is a flowchart of an example operation to perform additional authentication operations between the partnership system and a trusted mobile application from the perspective of the partnership system.
Petition 870190079542, of 16/08/2019, p. 80/148
7/61
Detailed Description [020] This disclosure describes systems and methods for authenticating identity through various authentication entities, for example, financial institutions with the use of a single trusted mobile device as a proxy for user login. Specifically, a combination of authentication based on layered technology and analytics is used to enhance the user experience during digital transactions, while also ensuring that adequate levels of authentication are received for important or potentially fraudulent activities.
[021] In this description, several parties may be involved in the authentication process. For the purposes of the description, the phrases “consumer”, “customer” and “partnership” can be used with each acting as a separate part of the process • The “consumer” can be a user or customer of a bank, financial institution or from another entity and whose mobile device can be digitally linked to personally identifiable information (Pll) associated with the user;
• The “customer” can be a bank or financial institution, as well as any other company, business or individual that uses a partnership system to manage and authenticate the users / customers associated with activities that occur in association with the customer. For example, the "customer" can be a bank, a store with a digital facade, a web-based shopping site, or any other suitable system that requires validation and authentication of users who access the system;
• “Partnership” represents a backend system capable of authenticating individual users and their mobile devices in order to authenticate specific users in a centralized and uniform manner, particularly based on linked mobile devices.
Petition 870190079542, of 16/08/2019, p. 81/148
8/61 [022] The solutions described in this application provide customers (for example, banks and other authenticating entities) with a more accurate level of risk of fraud in a set of universal and shared information about a specific user and their mobile device. In addition, authentication techniques can be defined and applied based on the type of transaction to be carried out, thus allowing customers the ability to request additional or more specific information from consumers in situations where the action being performed or requested by the consumer is determined to require additional authentication to allow for a higher level of trust and / or identity assurance, or when a greater possibility of potential fraud is present and, in addition, trust is useful. Additional authentication factors may include, for example, single pass codes, biometric entry and verification, push notifications and other appropriate factors. Advanced analytics and network insights (for example, consumer information from one or more additional or alternative sources) can be used as additional verification and fraud detection input or consideration information, providing an additional layer of analysis and input for system authentication operations.
[023] In a similar way, consumers are associated with a complete application (one-stop application) and a shared digital identity that can be used in various entities to safely interact with consumer and Pll credentials, reducing the number and the extension of information sharing necessary to authenticate the consumer, while also accelerating specific transactions that were previously slowed down by manual login techniques. In many cases and scenarios, consumers may no longer need to share or provide their Pll with individual entities after initial registration, reducing points
Petition 870190079542, of 16/08/2019, p. 82/148
9/61 potential weaknesses in identity protection.
[024] The present disclosure provides a universal digital consumer ID, which can be used as a secure digital credential of the consumer's identity. Rather than being based solely on something the consumer knows (for example, knowledge-based authentication and ID / password combinations), the digital ID represents a virtual connection between the consumer and his device. In one example, digital ID represents a combination of several authentication techniques that can encompass three common authentication techniques: (1) what you know, (2) what you have and (3) what you are. Once the digital ID is connected to the specific consumer, the digital ID can be passively verified and confirmed through participating businesses and government entities that also know and interact with the consumer linked to the digital ID. This combination of customers (for example, these companies and government entities) associated with the partnership system that provides the digital ID can be cited as a digital network ID, where the interconnectivity and the corroboration of perception between the parties allows for high confidence accurate and passive.
[025] In some events, such as those identified as low risk (for example, by the customer), consumers may be able to access specific participating systems using their mobile device alone without interactions, unlike current systems. However, when a high risk situation is detected in association with a digital ID exchange, or when a high risk or high-value transaction requires additional guarantees and / or more security before authorization, the digital ID and the consumer linked to the your mobile device can allow businesses or government entities to interact securely, through the digital channel, with the consumer through a dedicated, trusted mobile app. With the use of a dedicated, trusted mobile application, the customer and / or
Petition 870190079542, of 16/08/2019, p. 83/148
10/61 partnership can ask for and receive additional information or data (for example, a knowledge-based question, biometric data entry, etc.) that can be used to perform additional authentication operations. The ability to conditionally invoke this interaction through a secure and protected channel based on the type of transaction or attempted interaction or based on the particularities of the transactions or interactions themselves, including based on customized or specific rules by customers associated with the system, complements the robust risk assessment behind the scenes, based on the comprehensive and shared insight provided by the information through various participating entities.
[026] In addition to providing customers with significant benefits, digital ID and support procedures can enable consumers to manage, monitor and control the use of their digital ID and allow the digital ID to be universally accepted and used by participating entities with whom they choose to share it.
[027] The advantages of the described process and system are numerous. Existing online authentication is enhanced by simplifying the online user experience through digitally linked mobile devices that are used to assist in consumer verification and authentication for any participating system associated with the digital ID network. In addition, based on the type of transaction to be carried out, the specifications of the specific transaction to be carried out, and / or other potential fraud predictors, improved levels of security and additional authentications can be triggered and provided through a digital channel for a single location (that is, the trusted mobile app), where the consumer can provide additional information securely to obtain the high security requirement. The digital ID allows the subject's identity (that is, the consumer) to be actively and passively a part of the authentication process, so that the cycle
Petition 870190079542, of 16/08/2019, p. 84/148
11/61 security structure feedback allows for faster and more accurate detection of suspicious activity and fraud. Furthermore, the digital ecosystem allows participating entities to trust the digital ID provided as a true proxy for the consumer (and their identity) with which the entities are interacting, providing an improved level of trust in each transaction carried out in conjunction with the Digital ID.
[028] Although there is the authentication capability that binds the device and sends notification, the main use of these techniques is used by individual customers in isolation. The current solution uses the consortium network of participating customers and information collected in the partnership system, as well as additional third party data available, when available, to create a highly informed and federated identity network that is reinforced by information and understanding shared between entities . The network allows the use of signals, perceptions and feedback mechanisms from previous and current actions, as well as an analysis of similar consumers, to more accurately detect fraud and / or conditions that require more authentication interactions.
[029] In order to take advantage of the federated digital ID network, consumers can be directed to register on the network by one or more customers / applications or applications when a consumer is not previously registered. Specifically, customer's applications or applications may offer links (links) to a registration interface for the back-end partnership system, allowing the consumer to register and be associated with a trusted digital ID. The registration / registration process can be used in association with the user's mobile device (for example, a phone, tablet, etc.) to complete the registration process.
[030] First, the consumer can select the option to register in the partnership system. To do this, a mobile application
Petition 870190079542, of 16/08/2019, p. 85/148
12/61 trustworthy (for example, different from the consumer browser and a mobile application or customer websites) provided or associated with the partnership system can be made available to the user, so that the user can download and install the Trusted mobile app. The consumer can enter a set of personally identifiable information (P11) in a registration area of the customer's website or application, where that information is then passed back to the partnership system and associated with the consumer.
[031] In response to the receipt of the Pll from the consumer, the partnering system can perform a secure set of ID checks (“IDV”) through the Pll of the user, including accessing and taking advantage of various industry standard IPI confirmations and assessments . At or around this time, or in conjunction with verification, a set of fraud risk assessments can be carried out for the consumer, where fraud risk assessment operations can identify and store information within the partnership system on the relative risk and / or fraud associated with the consumer. In some cases, consumers determined to be associated with factors that indicate potential and / or significant fraud risks, including, but not limited to, consumers using paired mobile devices that are not located close to the current device used to access the webs / banking application / app, multiple consumers associated with the same government ID or using a common device, a single consumer identity being used on multiple bank sites simultaneously, or those who cannot have their identity verified through normal means, may not allowed to create a digital ID as described in this application. Fraud risk assessments that can prevent the consumer from being verified can include an unusual volume of interactions over the network for a specific Pll or mobile device, an unusual combination of past interactions (e.g.,
Petition 870190079542, of 16/08/2019, p. 86/148
13/61 change of address combined with a new registration of a new device), a high volume of rejected transactions, previous data associated with the provided Pll identified as a relatively high risk, a low volume or set of knowledge of the Pll information, a device signature mismatch (e.g., primary and secondary channel signature mismatches), and sets of mismatches of Pll information provided in comparison to a carrier's Pll information, as well as any other appropriate assessment and / or determination.
[032] Once the consumer passes the initial IDV and the risk criteria checks, the partnership system can generate a unique code and send the unique code and / or a representation of the unique code (for example, a QR code ( or “Quick Response”)) to the customer's website or mobile application (where appropriate), where the unique underlying code is specifically associated with the consumer who performs the registration process. The unique code representation can uniquely encode information used to verify the consumer and the consumer's mobile device. The purposes of representing a single code, such as a QR code, are the bridge of trust between channels in an out-of-band manner. The trust of the primary channel (for example, an online banking session in which the device user has already logged in) is inferred or transferred to the consumer's mobile device using the unique code. In some cases, the unique code may be provided without encoding (for example, as a string). To complete the link from the mobile device to the consumer, the consumer may be asked to take a picture of the representation of the unique code (for example, the QR code) or the exact single code (for example, when the unique code is provided directly without coding ) via the trusted mobile application downloaded. Atoto can be taken as a screenshot (if captured on or by the mobile device), a photo taken from a desktop system
Petition 870190079542, of 16/08/2019, p. 87/148
14/61 by the mobile device (and stored in the device's photo library) or any other suitable method. The unique code photo can then be presented by the trusted mobile application for the partnership system and verified / authenticated. Other methods for entering the unique code, except using the device's camera, can be used instead. Once the photo or entry of or associated with the unique code is captured, the trusted mobile app is used to link the consumer’s PH and other information with a set of information specific to the mobile device to create the consumer’s digital ID for use in future systems.
[033] In general, the digital ID can take the form of an alphanumeric code (or other suitable identifier) that represents a specific consumer record or consumer profile that matches a specific consumer Pll (for example, name, address, date number and / or social security number (SSN), etc.) with a phone number, email address, biometric pattern of the consumer's fingerprint or iris, and / or another unique identifier (for example, a unique username), etc., and device data (for example, IP address and other identifiers and / or data associated with and / or related to the device, etc.). In some cases, the digital ID can be a combination of these values, a unique identifier that links, includes or is associated with the information set. Once registered, the digital ID can be considered or treated as a primary digital ID used by the partnership system to uniquely identify the specific consumer, in combination with the consumer's device in interactions with the trusted mobile device and across the network. confidence. In addition to the primary digital ID, each customer can have a unique customer-specific digital ID generated by them, where customer-specific digital IDs are used by the various customer systems to interact with the partnering system, avoiding potential problems that may arise. result when one or more customers are
Petition 870190079542, of 16/08/2019, p. 88/148
15/61 committed. In other words, the digital ID represents a unique identifier or key that is created to restrict an individual consumer Pll, device and activities together, and that allows consumers to be identified without the actual Pll being transferred. The customer can maintain decision and execution management related to the use of the customer's specific digital ID and the information and accounts associated with the digital ID on the customer. For example, how the customer sets up or implements the solution is managed by the customer, thus allowing customers to configure the solution as they see fit for internal operations. Additional participating entities associated with the partnership system may also use a link to the main digital ID, in the form of an entity-specific digital ID, in some cases, provided by the partnership system, for future transactions upon registration in the partnership and sharing system customer-specific account information as linked to the primary digital ID.
[034] The partnering system and the trusted mobile application use data about consumer interaction with a specific digital interface of customer systems (for example, mobile applications, websites, other suitable entry points), combined with data about the registered mobile device (eg geographic location, installed software, etc.) to authenticate the consumer. In addition to this authentication, additional analysis on the consumer can take place within the partnership system to assess the type of transaction that the consumer is carrying out in connection with (1) one or more valuation rules, which can be configured or selected by the customer, and / or (2) potential fraud indicators. Depending on the type of transaction and the results of the additional analysis, the partnership system can determine whether additional degrees of resistance or interactions are required by the consumer before authorizing the requested transaction based on specific customer evaluation rules and indicators
Petition 870190079542, of 16/08/2019, p. 89/148
16/61 of potential fraud.
[035] In general, the solution can allow customers to implement adaptive authentications based on the context. Typically, security is placed at the entrance to the website or at a location before allowing access to the data being protected. Once successfully authorized (for example, after using obtained credentials or otherwise exceeding security measures), potentially malicious users may be free to operate and interact with the compromised system and / or data. With the present solution, adaptive authentication is provided to require varying levels of security on a need or rule based on context. Several sample transactional experiences are provided in this document, although any number of experiences are considered and included in this disclosure;
• A consumer tries to sign in to a customer's website. In response to the login attempt, the partnering system sends a message to the consumer (via the trusted mobile app) to verify that he or she is trying to sign into the account on the customer's website. The consumer can select “yes” or “no” in response and before the login is accepted and authorized;
• A consumer logs on to a customer's website on a desktop computer or system other than the mobile device. The partner system evaluates the digital information on the website and information about the location of the mobile device (and any other appropriate information) to determine whether the mobile device is physically close to the consumer. If so, the partnership system allows and approves a consumer login without additional consumer interaction;
• A consumer logs on to a customer's website and initiates a transaction, where the customer is associated with a
Petition 870190079542, of 16/08/2019, p. 90/148
17/61 security / high authorization defined by the customer for transactions on the specific quantity. The partnering system identifies the transaction and applies the customer-defined rule by forcing a request to the consumer's mobile device to obtain additional authentication, such as a biometric data request (for example, a fingerprint or voice analysis) or an authentication questionnaire ID. If the request for additional ID authentication is approved, the transaction request is authorized by the partnership system and the transaction can then be approved and completed on the website and systems submitted for normal approval;
• A fraudster has possession of the consumer's mobile device and the code to unlock the device. While in possession, the criminal attempts to log into the customer's website using the consumer's mobile device while outside a traditional location associated with previous logins, as monitored or known by the partner system. The partnership system evaluates the incoming request and website information associated with the login and determines that the login request originates outside the consumer's usual location interaction area (for example, outside the consumer's country of residence , outside a city typically associated with the consumer's location, etc.). In response, the partnership system can send a message to the consumer via the trusted mobile application in a request to authorize the login. Due to the fact that the consumer is not the requester of the login request, the partnership system can request additional authentication through the trusted mobile application, such as a password, question / answer challenge, biometric information, where the fraudster would not be able to provide the additional requirements to successfully authenticate the consumer.
[036] While these are four examples of potential scenarios,
Petition 870190079542, of 16/08/2019, p. 91/148
18/61 it is noted that the types of activities associated with high security and authentication requests with the partnership system can be actively managed, so that any particular interaction with the customer's systems can be associated with relatively higher levels and / or lower authentication levels, as identified by the customer and / or the partner system. In addition, in situations where the partnering system identifies a potential fraudulent attempt outside the defined authentication requirements and regardless of the specific activity, additional authorization interactions can be generated or initiated by the partnering system to stop potentially fraudulent access to any specific data , regardless of whether the specific activity or interaction is associated with a high or low level of action related to authentication.
[037] The described system therefore uses a combination of authentication methodologies and technologies, including analysis and modeling of individual and cohort-based considerations to bring a holistic view of the consumer. This holistic understanding of the consumer, based on data about the device, the interface with the customer's systems and the activity in relation to current and historical consumer activities across the digital ID network, among others, provides a unique and innovative solution. for companies, government organizations and other entities.
[038] Returning to the illustrated implementation, Figure 1 is a block diagram illustrating an example system (100) for implementing a digital ID network through a plurality of consumers (also referred to as “users”) and customers. As illustrated in Figure 1, the system (100) is a client-server and client-device system capable of sharing and communicating information across a set of devices (for example, one or more mobile devices (101), one or more clients (130) and a partnership system (160) via the network (120)). In the present illustration, one or more
Petition 870190079542, of 16/08/2019, p. 92/148
19/61 partner systems (160) can provide the digital ID network, where one or more customers (for example, companies and / or government entities) carry out transactions with one or more consumers or users associated with specific mobile devices (101 ). Although components are shown individually, in some implementations, the functionality of two or more components, systems or servers can be provided by a single component, system or server. The partnership system (160) provides consensus-based authentication, where several relatively small data points can represent a larger image rather than relying only on knowledge factors. In addition, data points can extend across different partners in the network of participants associated with the partnership system (160), including information related to an unusual volume of interactions across the network for a given set of Pll and / or device ( for example, a change of address combined with a new registration of a new device), a high volume of rejected transactions associated with one or more systems associated with the partner systems (160), a set of previously identified data that identify Pll such as a potential high risk, a relatively low amount of knowledge associated with Pll information, or a device signature mismatch (for example, failure to match primary and secondary signatures), among others.
[039] As used in this disclosure, the term "computer" is intended to encompass any suitable processing device. For example, both the client system (130) and the partner system (160) can be any computer or processing device, such as one or more servers, blade servers, general purpose personal computers (PC), Mac ®, workstations, UNIX-based workstations, or any other suitable devices. Besides that,
Petition 870190079542, of 16/08/2019, p. 93/148
20/61 although Figure 1 illustrates a single partnership system (160), the partnership system (160) can be implemented with two or more systems, as well as computers, except servers, including a server group. In other words, the present disclosure contemplates computers, except general purpose computers, as well as computers without conventional operating systems. Likewise, the mobile device (101) can be any system that can be linked to the user associated with it, and can include a mobile device, a tablet, a smart watch or any other suitable mobile computing device specifically associated with and linked to the specific user registered on the digital ID network. In some cases, non-mobile devices, if appropriate, can be associated and linked to a specific digital ID. In addition, although not shown, one or more additional systems can also be used by the user to access specific customer systems (130). In such cases, interactions between the user and the client's systems (130) can be performed by other computers, including desktop computers, other mobile devices, and any other suitable computer. The partnership system (160) can analyze the presented digital ID and determine if and how additional interactions with the mobile device (101) may be necessary to authenticate the user in its entirety. In general, each illustrated component can be adapted to run any suitable operating system, including Linux, UNIX, Windows, Mac OS®, Java ™, Android ™, Windows Phone OS or iOS ™, among others. In some cases, two or more separate partnering systems (160) may also be provided.
[040] In general, the mobile device (101) is used as a specific device linked to a specific user, whose digital ID is used within the digital ID network provided by the partnership system (160). The mobile device (101) comprises an electronic computing device operable to receive, transmit, process and store any data
Petition 870190079542, of 16/08/2019, p. 94/148
21/61 associated with the environment (100) of Figure 1. In particular, the mobile device (101) can run one or more general mobile applications (104), a trusted mobile application (105) used to verify and authenticate the user identity through the mobile device (101), and any other appropriate components and / or operations.
[041] As illustrated, the mobile device (101) includes an interface (102), a processor (103), a mobile application (104), a trusted mobile application (105), a GUI (108), one or more input devices (109), a location module (112), a camera (118) and memory (113). The interface (102) is used by the mobile device (101) to communicate with other systems in a distributed environment, including within the environment (100), connected to the network (120), for example, the customer's system (s) (130 ), the partnership system (160), and other mobile devices (101), as well as other communicable systems connected to the network (120). Generally, the interface (102) comprises logic encoded in software and / or hardware in a suitable and operable combination to communicate with the network (120). More specifically, the interface (102) can comprise software that supports one or more communication protocols associated with communications so that the network (120) or the interface hardware is operable to communicate physical signals within and outside the illustrated environment (100 ). In addition, the interface (102) may allow the mobile device (101) to communicate with the partner system (160) or a customer system (130) to perform operations related to the present disclosure.
[042] The network (120) facilitates wireless or wired communications between components of the environment (100) (for example, between the mobile device (101) and the partnership system (160), between the mobile device (101 ) and the customer's system (s) (130), and between the customer's systems (130) and the partner system (160)), as well as with any other local or remote computer,
Petition 870190079542, of 16/08/2019, p. 95/148
22/61 as additional mobile devices, clients, servers or other communicable devices connected to the network (120), including those not shown in Figure 1. In the illustrated environment, the network (120) is represented as a single network, but can be understood for more than one network without departing from the scope of this disclosure, therefore, provided that at least a portion of the network (120) can facilitate communication between senders and recipients. In some cases, one or more of the components illustrated (for example, the partnership system itself (160) and / or one or more of the customer's systems (130) may be included within the network (120) as one or more services or cloud-based operations The network (120) can be all or part of a company or protected network, while in other cases, at least a portion of the network (120) can represent an Internet connection. , a portion of the network (120) may be a virtual private network (VPN). In addition, all or a portion of the network (120) may comprise both a wired and wireless connection. Examples of wireless connections may include 802.11a / b / g / n / ac, 802.20, WiMax, LTE and / or any other appropriate wireless connection, in other words, network (120) encompasses any internal or external network, networks, subnetwork or combination thereof, operable to facilitate communications between the various computing components inside and outside the illustrated environment (100). network (120) can communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data and other appropriate information between network addresses . The network (120) can also include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs) and wide area networks (WANs), all or a portion of the Internet and / or any other communication systems or systems in one or more locations.
[043] As shown in Figure 1, the mobile device (101) includes a processor (103). Although illustrated as a single processor (103)
Petition 870190079542, of 16/08/2019, p. 96/148
23/61 in Figure 1, two or more processors can be used according to specific needs, desires or specific implementations of the environment (100). Each processor (103) can be a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable port arrangement (FPGA) or other suitable component. Generally, the processor (103) executes instructions and manipulates data to perform the operations of the mobile device (101). Specifically, the processor (103) performs the algorithms and operations described in the illustrated figures, including the operations that perform the functionality associated with the mobile device (101) in general, as well as the various software modules (for example, the mobile application ( 104) and the trusted mobile application (105)), including functionality to send communications and receive transmissions from the customer's systems (130) and partner systems (160), as well as to other mobile devices and systems.
[044] Regardless of the specific implementation, the "software" includes computer-readable instructions, firmware, wired and / or programmed hardware, or any combination of them in a tangible medium (transient or non-transient, as appropriate) operable when executed for perform processes and operations described in this application. In reality, each software component can be totally or partially written or described in any appropriate computer language including C, C ++, JavaScript, Java ™, Visual Basic, assembler, Perl®, any suitable version of 4GL, as well as others.
[045] The mobile device (101) runs a mobile application (104) operable to perform any functionality suitable for the mobile device (101). In some cases, several mobile applications (104) can be included and run on the mobile device (101), such as running mobile applications on mobile OS systems. In some cases, one or more of the
Petition 870190079542, of 16/08/2019, p. 97/148
24/61 mobile applications (104) can be operable to interact with one or more of the customer's systems (130). In some cases, these applications may be developed and provided by the customer associated with the customer's system (130) (for example, a dedicated mobile application, such as those downloaded or obtained from an app store), while in others, applications (104) may be or be associated with a general mobile browser capable of mobile navigation, where specific interactions with customer systems (130) may be optional, if directed to a website or system associated with the customer's system (130). In some cases, interactions with the customer's systems (130) can be performed by another system associated with the user, but not linked to the user's digital ID. In such cases, the partnership system (160) can connect to the mobile device (101) via the trusted mobile application (105) to access and obtain information about the user and the mobile device (101), where and when needed.
[046] The trusted mobile application (105) represents a mobile application or combination of dedicated applications to provide a secure link (link) between the user and the mobile device (101), where the user's digital ID, as described in the present order, is linked to the mobile device (101) during a registration process performed by the registration module (106). The registration process can be initiated based on a user interaction with a specific customer application (133), where an option to register a new digital ID can be presented through one of the mobile applications (104), or through a separate channel (for example, through another device or another application except through the trusted mobile application (105)). During registration (as described in an example implementation in Figure 3), the user can, through the customer's system (130), provide personally identifiable information (Pll), which identifies the user (for example, name, address, date of birth, social security number (SSN),
Petition 870190079542, of 16/08/2019, p. 98/148
25/61 driver's license number, etc.) for the partnership system (160). De partnership system (160) can, through its various components and features described below, evaluate and validate the user's PLL to verify the user's identity. At the same time, the partnership system (160) can assess potential fraudulent risks associated with the user based on the set of initial information provided and / or any previous information about the identified user (for example, industrial database and reports or government agencies such as credit agencies, criminal databases, etc.). If the user is approved as meeting or exceeding the risk requirements of the partnership system (160), the partnership system (160) can generate and supply, through the customer's system (130) (or through any other suitable method) , a unique code (e.g., a QR code) or other token or identifier that can be associated with the user, including, but not limited to, mobile phone carrier data, for the user to capture via the trusted mobile app ( 105). The unique code (or an appropriate representation of it) can be captured, for example, by a camera (118) that is part of or associated with the mobile device (101) as accessed through the functionality of the trusted mobile application. Alternatively, the trusted mobile app (105) may be able to access a camera roll or a photo library of captured images to identify and load the unique code (or an appropriate representation of the unique code as provided) back to the partnership system (160). In realizations that employ unique non-visual codes (such as a token or identifier), the unique code can be captured and responded to through recognition and / or decryption mechanisms as appropriate. In response to confirmation that the unique code (or representation thereof) is captured by the trusted mobile application (105), the partnering system (160) can view the mobile device (101) as a trusted device and, through
Petition 870190079542, of 16/08/2019, p. 99/148
26/61 of a key management application (170) of the partner system (160), a private key (115) specific to the user's authorized digital ID can be generated and stored on the mobile device (101). A corresponding customer-specific digital ID or other unique identifier can be provided for each customer that interacts or has an account associated with the user, so that any customer interaction with the partner system (160) can link the customer's specific identifier to the Primary digital ID. The customer-specific digital ID can then be used on any customer system (130) associated with the partnership system (160), where the partnership system (160) can evaluate transaction requests using the secure evaluation system described in this application , using the link to the primary digital ID for the specific user / consumer.
[047] The trusted mobile app (105) as illustrated, also includes an authentication module (107). The authentication module (107) can be used, for example, in association with transaction attempts on customer systems (130) including the digital ID network to provide details and information from the mobile device to the partner system (160) during or in association with the transaction request, to present additional authentication / challenge requests to users via the mobile device (101) in response to high security transactions (as predefined by customer systems (130)) or in response to security determinations potential fraud associated with specific transactions via the partnership system (160) and to provide responsive entries for additional authentication requests / challenges presented through the trusted mobile app (105). In some cases, additional authentication / challenge requests can be presented to users via GUI (108).
[048] GUI (108) of the mobile device (101) interfaces with at least a portion of the environment (100) for any suitable purpose,
Petition 870190079542, of 16/08/2019, p. 100/148
27/61 including the generation of a visual representation of a mobile application (104) and / or the trusted mobile application (105). In particular, the GUI (108) can be used to view and navigate through multiple screens, for example, web pages, located both internally and externally to the environment (100), as well as to view and navigate through information accessed by anyone of the mobile applications (104) and / or trusted mobile application (105), this information stored or associated with one or both of the system (s) (130) and of the partnership system (160), among others. Generally, the GUI (108) provides the user with an efficient and user-friendly data presentation provided or communicated within the system. The GUI (108) can comprise a plurality of customizable frames or views that have interactive fields, drop-down lists and buttons operated by the user. For example, the GUI (108) can provide interactive elements that allow a user to view or interact with information related to the process operations associated with the trusted mobile application (105) and its authentication processes. The GUI (108), for example, can be where the user is provided with authentication questions / challenges and is able to provide feedback (for example, answers) to the partnering system (160). In some cases, the GUI (108) can be associated with one or more input devices (109), including a biometric reader (110) (for example, a fingerprint scanner, facial recognition, speech / command recognition, etc. .) or a touchscreen / keyboard (111) (as well as other buttons, inputs, etc.) to allow for responsive feedback and interactions for the authentication issues provided. Additionally, the GUI (108) can present information associated with one or more of the mobile applications (104) for viewing and interacting with one or more customer systems (130). In general, the GUI (108) is often configurable, supports a combination of tables and graphs (bars, lines, pie, status displays, etc.) and is capable of creating
Petition 870190079542, of 16/08/2019, p. 101/148
28/61 portals and presentations in real time, where tabs are outlined by the main characteristics (for example, website or micro-website). Therefore, the GUI (108) includes any suitable graphical user interface, such as a combination of a generic web browser, intelligent engine and command line interface (CLI), which processes the information on the platform and efficiently presents the results visually. to the user. In addition, the GUI (108) can also allow the consumer to manage their own security preferences through the trusted mobile app (105). For example, the consumer could block or otherwise protect items associated with the consumer's digital wallet while in military mobilization or traveling for an extended period, so that any attempted transaction associated with the consumer's digital ID can be rejected or otherwise requires additional authentication.
[049] A location module (112) can be included within the mobile device (101), and can be used to identify a specific location in which the mobile device (101) is currently and has historically been located. The current location specific to the mobile device (101) can be provided to the partnering system (160) (for example, via the transaction request passed from the customer's system (130) or via the trusted mobile application (105) ). If the current location of the mobile device (101) is different from the location in which the request was received (for example, through a channel far from the mobile device (101), the partnering system (160) can detect an occurrence of fraud in potential, and may initiate procedures to perform additional authorization operations, including sending a confirmation or other challenge to the mobile device (101) via the trusted mobile application (105) .In addition, if both the transaction request and the mobile device (101) are identified as originating and are located in a
Petition 870190079542, of 16/08/2019, p. 102/148
29/61 location other than that normally associated with the user (for example, outside the country, some distance from all previous locations, etc.), one or more fraud alerts can be identified by the partnership system (160). The location module (112) can be used to identify a specific physical location of the mobile device (101) or a logical or relative location of the mobile device (101) (for example, based on detected nearby wireless networks, connections to a or more computers or systems, check-ins or other location-based information, etc.) [050] The memory (113) of the mobile device (101) can represent a single memory or multiple memories. The memory (113) can include any memory or database module and can take the form of volatile or non-volatile memory, including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media or any other suitable location or remote memory component. The memory (113) can store various objects or data, including financial data, user information, administrative settings, password information, caches, applications, backup data, business storage repositories and / or dynamic information, and any other information appropriate devices associated with the mobile device (101) including any parameters, variables, algorithms, instructions, rules, restrictions or references to this. In addition, memory (113) can store any other appropriate data, such as VPN applications, firmware and policy logs, firewall policies, a security or access log, print or other report files, as well as others. For example, memory (113) can store one or more private keys in a private key store (114) located in memory (113), as well as a set of personally identifiable information (PII) (116), and a set of device-specific information (117). Storing the private key (114) can include associated private keys
Petition 870190079542, of 16/08/2019, p. 103/148
30/61 to one or more customer systems (130), as well as a private key (115) that corresponds to the digital ID generated and provided by the partnership system (160). Pll (116) can be stored on the mobile device (101) or can also be provided by the user in response to particular requests for Pll (116). In some cases, the Pll (116) may represent a link to which the specific Pll of the mobile device (101) are associated, so that no Pll is stored on the device except that which the consumer has stored on it. The device-specific information set (117) can be used to provide a fingerprint or mobile device identity (101) (for example, based on installed software, system information, etc.) that can be used in part to identify the mobile device (101). This information can be shared by the trusted mobile application (105) to the partner system (160) at the registry and, in some cases, in response to specific requests for additional authentication information to validate / authenticate the mobile device (101).
[051] As illustrated, Figure 1 includes one or more customer systems (130). Each customer system (130) can be associated with the digital ID network and can accept authorizations based on the digital IDs provided by the mobile devices (101). Customers may include, for example, without limitation, banks, financial institutions, online merchants, government systems, health insurance companies and doctors' offices, among others. Customer systems (130) can register with the partner system (160) to employ and accept digital IDs as substitutes or alternatives to traditional login information for users. Initially, each client system (130) can have an existing trust relationship with specific users (for example, those associated with mobile devices (101) before the digital ID is generated. In these cases, users can also be provided with the option to perform the registration options described in
Petition 870190079542, of 16/08/2019, p. 104/148
31/61 this application to link the consumer's mobile device (101) to the digital ID and trusted mobile application (105). Each customer system (130) can provide at least one customer specific application (133) or (website) that can be accessed and interact with users, where customer specific applications (133) can be accessed based on ownership of the Digital ID used throughout the digital ID network.
[052] Each client system (130) includes an interface (131), a processor (132) and memory (140), each of which may be similar or different to the interface (102), processor (103) and memory ( 113), respectively, described in the mobile device (101). The interface (131) provides the customer's system (130) with communications for the components and systems of the environment (100), including the ability to communicate with the mobile device (101), the partner system (160) and any other systems or computers over the network (120). In general, the processor (132) executes instructions and manipulates data to carry out the operations of the client system (130). Specifically, the processor (132) performs the algorithms and operations described in the illustrated figures, including the operations that perform the functionality associated with the client application (133). The memory (140) can be similar or different from the memory (113).
[053] As illustrated, the client system (130) is used to receive, manage and interact with multiple users through any number of interactions, including through mobile devices (101) (for example, mobile application (104)) or any other suitable computing system. The client application (133) can access and provide operations associated with confidential consumer records (142) stored in a consumer database (141) (in memory (140), which can be similar or different from memory (113) and, in some cases, may be at least partially located remote from the customer's system (130)), where consumer records
Petition 870190079542, of 16/08/2019, p. 105/148
32/61 (142) may include, for example, business and government information, including financial, health, business, government or other related information, where consumer application operations (133) are such that security concerns and procedures can be advantageous to use. Additionally, the client application (133) can be associated with several websites, and can be used to access or publish message boards, online e-mail programs, online productivity software, as well as any other software, applications or systems. The consumer database (141) can store information relevant to information related to the specific customer application, as well as include consumer data and information history (145). In addition, the customer application (133) can be associated with transaction and other business systems, such as enterprise software systems, including customer relationship management systems, supplier system suppliers, purchasing systems, human resources systems and supply chain systems, among others. Consumer records (142) can be associated with an internal ID (143) used previously to introduce the trust, which can be associated with a specific username / password combination, as well as other identifiers used within the system. customer (130). By generating the digital ID, the consumer records (142) can be updated to include a partnership ID (144), which can allow the customer's system (130) to correspond with the partnership system (160) for users / specific consumers, allowing quick access and analysis of specific users and transactions. The partnership ID (144) can be a unique key and / or globally unique identifier (GUID) that is used to link the internal IDs of the customer's system (143) to the digital ID used by the partnership system (160) and received from users when digital ID is provided for authentication of specific transactions, including
Petition 870190079542, of 16/08/2019, p. 106/148
33/61 session and other operations.
[054] In some cases, some or all of the consumer and historical data (145) can be shared with the partnership system (160). As several customer systems (130) store information associated with specific users, a better holistic view of these users can be provided if that information is shared and available to all systems. By sharing at least some of the consumer data and history (145) from various customer systems (130), the partnering system can provide better fraud tracking and detection.
[055] The memory (140) can also include a set of logical partnership rules (146). The logical partnership rules (146) can define customer-specific settings and selections / subscriptions for potential authentication operations to be performed by the digital ID network for interaction with the customer's application (133) and consumers attempting transactions with the customer's system (130). For example, logical partnership rules (146) may include a set of action authentication rules (147), which are defined by administrators in the customer's system (130) and coordinated with the partnership system (160), where these rules (147) define specific transactions or operations that may require an additional layer or level of user authentication, such as through the trusted mobile application (105). In some cases, the specific types of additional user authentication required can be specified in the action authentication rules (147), so that the customer's system (130) can determine and request specific authorization through the partnership system (160) . In some cases, requests for additional authorization available may be based on the techniques available in the partnership system (160) and / or the specific techniques for which the customer's system (130) is subscribed or authorized to use. For example, a customer may choose to use data-based authentication
Petition 870190079542, of 16/08/2019, p. 107/148
34/61 biometrics for specific transactions, electing not to provide a question and answer challenge. These can be cases where the type of transaction is subjected to higher levels of fraud, and where the biometric authentication steps provide more secure confirmation of the identity of the user / consumer associated with the transaction.
[056] In some cases, action authentication rules (147) may provide information and / or internal rules on how, upon receiving a score or assessment from the partner system (160), specific transactions will be handled. Scores received from the partnership system (160) can be relative or absolute, and can be interpreted by the customer's system (130) according to the rules (147), whether the transaction should be allowed or denied based on the results, whether additional authentication is required and any other appropriate analysis or rules, including specific wording or notifications to be provided to the user / customer. In some cases, the score required to authorize a particular type of transaction may differ between types of transaction, based on user / consumer information, or based on other contexts and / or information, both specific to a specific consumer, and generally based on recent interactions with a plurality of consumers. These variations can be included in the action authentication rules (147) and can be used to vary the requirements for specific transactions. In some cases, the partnership system (160) may determine that a potentially fraudulent activity is taking place outside the defined rules (147) of the customer's application (133) (for example, based on the location of the mobile device (101), with based on recent and / or previous fraudulent activity in another customer system (130), or based on other criteria), so that an additional assessment is necessary. Rules (147) can define when the results of the fraud assessment can trigger further verification or the process can be triggered
Petition 870190079542, of 16/08/2019, p. 108/148
35/61 automatically by the partnership system (160).
[057] As illustrated, logical partnership rules (146) can also include one or more request templates (148), where request templates (148) are used to define how information associated with a particular transaction is provided to the partnership system (160). For example, for each type of request, a different request template (148) may be available and used to identify the relevant user / consumer information to be provided. The request template (148) can be filled in at run time with the user / consumer partnership ID (144) for reference (160) via the partnership system (160) and, in some cases, the request template (148 ) can also identify a specific type of analysis and / or additional authentication to be performed. In other cases, the type of analysis and / or additional authentication can be determined by the partner system (160) based on the client system selections (130) previously shared. As such, the logical partnership rules (146) can be stored in their entirety in the customer's system (130), or at least some of the rules (146) can be located in the partnership system (160) when appropriate. In any case, the customer can call and define the appropriate rules to ensure that the customer's level of authentication is satisfied for each type of transaction and / or context.
[058] Returning to the customer's application (133), the application can be used to perform any relevant operation and the functionality associated with the customer's system (130). The customer application (133) as illustrated includes a consumer interface (134) and a partner interface. The consumer interface (134) provides the interface for interactions with the user / consumer through any suitable channel, including through the mobile application (104) of the mobile device (101) or through another system (for example, as a website or through a dedicated app or app). THE
Petition 870190079542, of 16/08/2019, p. 109/148
36/61 consumer interface (134) may include or be associated with a registration support module (135), where the opportunity to register with the partnership system (160) can be presented and assistance with registration. The registration support module (135) can manage the passing of information to and from the user (for example, through any channel information that occurs) and present information back to the user / consumer as needed, including the unique code generated by the partnership system (160). The registration support module (135) can provide a link (link) or access to the trusted mobile application (105), or it can assist in sending a link (link) to the mobile device (101) to download of the application (105) through text, email or any other method where the initial interaction does not occur through the mobile device (101). If the user / consumer is already registered, the consumer interface (134) can combine credentials provided by the user / consumer for a particular customer specific ID such as a login or transaction authentication technique. Whenever the customer wants to carry out risk-based authentication with the customer, the consumer can pass their digital ID to the partnering system (160). The customer-specific ID (which is different from the digital ID managed by the partnership system (160)) can be used to access internal operations and data at the customer level and with the customer's system (130). The customer-specific ID can be provided for the partner system (160) where authentication is required and / or when appropriate. By storing the internal digital ID in the partnership system (160) and not supplying the customer, the risk of compromising the entire set of keys (keyset) is mitigated if a single customer is compromised.
[059] The client application (133) also includes a partner interface (136) to interact and take advantage of the partner system's operations (160). The partnership interface (136) can allow the application of the
Petition 870190079542, of 16/08/2019, p. 110/148
37/61 client (133) (and other client applications) interact with the digital ID network through communications with the partner system (160), and can be used to interpret the logical partnership rules (146), prepare and submit requests to the partnering system (160) according to those requests and subsequently interpreting communications from the partnering system (160) to react to ID verification and fraud detection results, as appropriate. The partnership interface (136) can include a registration module (137) to communicate with the partnership system (160) when registering a new user / consumer. The partnership interface (136) can also include a customer management module (138), where the management module (138) allows administrators on the customer system (130) to modify the customer-specific logical partnership rules (146) , subscribe to specific verification techniques, and otherwise manage interactions and parameters available from the partnership system (160). The partnership interface (136) includes an authentication interface (139) that can handle sending and receiving authentication information received by the customer system (130) from the user / consumer to the partnership system (160) to provide the digital ID network authentication operations.
[060] In general, the illustrated modules of the customer's systems (130), the partnering system (160) or the mobile device (101) can be combined into a single application or module, in some cases. As noted, some of the software and information stored may be located or available remotely from the systems illustrated and described, including cloud-based systems.
[061] The partnership system (160) performs operations associated with specific transactions with holistic access received from one or more customer systems (130) associated with specific users, verifying the identity of users, evaluating any potential fraudulent activity
Petition 870190079542, of 16/08/2019, p. 111/148
38/61 and providing additional levels of security and confirmation requests where they are specifically elected by individual customer systems (130) or where a potential set of fraudulent activities is identified. Although illustrated as a single system, the partnership system (160) can be comprised of multiple systems, functions, modules and software, where appropriate.
[062] As illustrated, the partnering system (160) includes an interface (161), a processor (162), a consumer interface application (163) a customer interface application (171), a specific analysis module (173), a third-party system interface (178) and memory (179). The interface (161), processor (162) and memory (179) can be similar or different from the interfaces (102), (131), processors (103), (132) and memories (113), (140) described for the mobile device (101) and customer systems (130), respectively. In general, the processor (162) executes instructions and manipulates data to carry out the operations of the partner system (160), including the execution of the algorithms and the operations described in the illustrated figures.
[063] The consumer interface application of the customer system (160) is used to interact with the consumer through registration (through the mobile device (101) and / or any additional channels where the registration process was initiated, for example example, through a connection to the website on a desktop computer (desktop)) and interactions associated with authentication operations. As illustrated, the partnership system (160) includes a registration module (164), an authentication module (168) and a digital wallet management module (169).
[064] The registration module (164) can allow the user / consumer to carry out the necessary registration operations, as described in this application. In some cases, interactions with the customer's system (130) can initiate interactions between the registration module (164) and the consumer. In some cases, operations performed before installing the
Petition 870190079542, of 16/08/2019, p. 112/148
39/61 trusted mobile application (105) can be carried out through the client system (130) with which the registration process was started or through a web-based interface with the partnership system (160) (not shown) . A unique identifier generator (165) can generate unique identifiers (for example, QR codes) that can be used to identify specific users in the registration process that were initially authenticated during the registration process. The registration authentication module (166) can obtain or access Pll obtained provided by the consumer (for example, through the customer's system (130)) and perform (1) an identity verification process and (2) an initial verification process fraud assessment. The identity verification process can be managed by the registration module (164), for example, accessing one or more public or private databases or other third party systems (190) to confirm the identity of the user / consumer. During, before or after the identity verification process, the registration authentication module (166) can perform the initial fraud assessment process associated with the user / consumer to filter against identity elements associated with the fraud. In some cases, module (166) can check to determine whether the provided (and potentially verified) identity was associated with previous fraudulent activity or whether the Pll identity or information has been associated with one or more cybersecurity breaches in the public sector or private. Credit bureau checks may be initiated in some cases to determine whether fraudulent activity associated with Pll has previously been reported. Alternative and other methods can be used to determine if the identity or person is a potential fraud risk, including Pll correspondence associated with the user / consumer to known high risk Pll, Partner Pll, Support Pll and other available sources. The speed of information related to PLLs (for example, transactional speed and / or behavioral speed) can also be assessed and
Petition 870190079542, of 16/08/2019, p. 113/148
40/61 considered. Other data sources can also be used in the initial analysis, as appropriate. In some cases, the registration authentication module (166) can access the consumer analysis module (175) to perform initial ID verification and fraud assessment operations.
[065] Once the identity is verified and the potential risk of fraud associated with the identity is determined to be within acceptable limits by system requirements, the unique identifier can be generated and / or associated with your identity. As described, the unique identifier can be provided to the user / consumer through the channel through which the registration process was started, and instructions can be provided to the user / consumer to download the trusted mobile application (105) and, subsequently, capture an image of the unique identifier (and / or a coded version of the unique identifier) through the application (105). The captured image can be delivered to the partnering system (160) from the trusted mobile application (105) on a second communication channel that is different from the channel through which the registration process starts. After verifying that the captured image corresponds to the identifier generated in a unique way or that the captured image includes the identifier generated in a unique encoded way, the mobile device (101) can be considered registered. In some cases, a private key (for example, private key (115)) can be generated for the mobile device (101). Additionally, the unique digital ID can be considered registered and made available for use in client systems associated with partnerships (130). An identity link module (167) can perform and / or manage the specific user / consumer association with the mobile device (101). A key management application (170) of the partner system (160) can generate a GUID, i.e., the partner ID (144), for use by the customer system (130) associated with the record. As additional customer systems (130) associated with the partnering system (160) are used
Petition 870190079542, of 16/08/2019, p. 114/148
41/61 or interact with the user registered in the system, additional unique keys can be generated and supplied to the other systems (130) by the key management application (170). The partnership IDs (144) are different in each customer system (130), if a particular partnership ID (144) is exposed or lost, the partnership system (160) can simply generate a new partnership ID (144) which corresponds to the specific system (130) that needs a new GUID without requiring the registration process to be performed again. As authentication and validation requests are provided by the customer's systems (130), the GUID corresponding to the user of these systems (130) can be included in the request and identified in the partner system (160).
[066] The authentication module (168) can manage authentication operations performed after the initial registration, and can manage the sharing and verification of additional authorization operations between the partner system (160) and the mobile device (101). The authentication module (168) can communicate with the trusted mobile application (105) in a secure manner, providing additional authentication requests to the mobile device (101) and receiving responses on return.
[067] The digital wallet management module (169) can allow users / consumers registered with the partnership system (160) to manage their digital wallets, review the associated client systems (130) where their digital ID can be used , update information about their user / consumer and perform any number of account management activities. The ability to monitor and manage the information associated with themselves can allow significant freedom and protection for the user, including information about potential fraudulent transaction attempts identified by the partnering system (160), including with which customer systems (130) these attempts occurred, as well as information held by potential attackers, among other data.
Petition 870190079542, of 16/08/2019, p. 115/148
42/61 [068] The customer interface application (171) is used by the partner system (160) to interact with customer systems (130) during registration, to perform authentication and fraud monitoring, and to allow administrators and authorized users update and manage particular customer-specific rules and operating parameters. In some cases, communications from the client systems (130) can be received in the client interface application (171), which may include or be associated with one or more application programming interfaces (APIs) and / or other points endpoints to which communications can be provided by customer systems (130). In some cases, incoming communications can be represented as requests (based on request templates (148)), where the customer's system (130) is identified along with the unique partnership ID (144) associated with that specific customer system. customer (130). In some cases, specific authentications to be performed are identified in the requests, while in other cases, the client interface application (171) may use one or more client-specific authentication rules (186) stored in memory to perform the authentication. analyze. In some cases, a combination of stored customer rules and stored partnership rules can be used. When a request is received from a customer system (130), the customer interface application (171) can provide the request for the customer-specific analysis module (173). When a customer system (130) requests to interact with your customer system account (130), the customer management interface (172) can be executed by the partner system (160) to determine how to operate for the specific customer, including the ability to update / review which authentication techniques will be used when, or to modify parameters for specific operations to be performed.
[069] The customer-specific analysis module (173) can be a
Petition 870190079542, of 16/08/2019, p. 116/148
43/61 separate module from the client interface application (171), or a portion of it. The customer-specific analysis module (173) can manage the evaluation of specific analysis requests received from a customer-specific system (130), where module (173) interprets the request, its content, and all associated metadata to determine how to process the request. The determination of the type of analysis (174) of the module (173) uses information and context about the request to determine the type of analysis to be performed in the transaction provided by the customer's system (130). In one example, the analysis request may include an explicit indication of the type of transaction to be analyzed and information about which authentication techniques will be applied. In other cases, the request may include implicit information related to the transaction request, so the determination of the type of analysis (174) may need to determine the type of transaction request to be performed. In some cases, the request may include specific authentication techniques to be applied to the transaction request, while in others, the particular type of transaction can be cross-referenced to one or more of the customer-specific authentication rules (186) to determine the type of additional authentication that may be required / desired by the customer's system (130).
[070] The consumer analysis module (175) can perform specific consumer analysis as needed or requested by the customer's system (130). In some cases, one or more ID verification operations can still be performed or information about the request can be evaluated. A scoring module (176) can generate a relative and / or absolute score for the user and the request, where specific limits (relative or absolute) can determine whether problems are identified and whether additional verification and authentication may be required. A fraud assessment mechanism (177) can compare the request for fraud
Petition 870190079542, of 16/08/2019, p. 117/148
44/61 transaction and information associated with an ongoing analysis of consumer records, along with information associated with the transaction request, including information obtained from the mobile device itself (101). For example, the fraud assessment mechanism (177), in response to receiving a transaction request associated with a specific user / consumer, can obtain information about the status of the mobile device (101), both from the mobile application of trust (105) as from information included in the transaction request. The fraud assessment mechanism (177) can compare known and / or recent information associated with the user / consumer to identify whether any potential fraudulent behavior can be identified. In some cases, each transaction request may have a fraud detection assessment performed on it, while in others, only some of the transaction requests can be assessed for fraud (for example, when a particular customer-specific authentication rule ( 186) asks for this assessment). The fraud assessment mechanism (177) can be based on the results of an assessment on a set of fraud assessment rules and standards (185), which define a set of potential fraudulent flags or patterns of behavior. Fraud assessment rules and standards (185) can define examples of changes or transitions in transactions based on user / consumer history, on a specific set of transaction information that can be potentially fraudulent, on a location comparison of mobile device (101) compared to an expected or normal location, as well as any other suitable standards and / or rules. Comparing the consumer request, the device information associated with the mobile device (101) (e.g., absolute location, IP address, etc.) sends the request, the transaction speed of previous and recent transaction requests, specific data in
Petition 870190079542, of 16/08/2019, p. 118/148
45/61 transaction and other parts of the transaction and associated information, the fraud assessment mechanism (177) can assist in determining potential fraud cases. As noted, when multiple customer systems (130) are included in the digital ID network and obtain consistent and maintained information about specific users / consumers, historical transaction data (184) (which can be stored in memory (179)) can be used to assist in the assessment. Additionally, fraud assessment rules and standards (185) can be updated based on fraudulent behavior determined by users, except for the current user / consumer, where determinations of fraudulent behavior in relation to the accounts of others can be used to identify new fraudulent behavior on the current user / consumer.
[071] A series of determinations carried out by the partnership system (160) can rely on information stored outside, remote or external to the partnership system (160). In such cases, a third party system interface (178) can be used to contact and obtain information from one or more third party systems (190). Third party systems (190) can be any systems outside the partnership system (160) that store information related to consumer accounts and data (191), specific trends in fraudulent behavior, including additional and alternative fraud assessment rules and standards , as well as other information relevant to the evaluation of the Pll information system for users / consumers and transaction data associated with specific transaction requests.
[072] As illustrated, the partner system's memory (179) (160) includes a set of ID verification rules and options (180), where these rules (180) can be used in the consumer's initial assessment on the record, as well as when you need additional authentication during
Petition 870190079542, of 16/08/2019, p. 119/148
46/61 transaction requests. Rules (180) can define how these requests are presented to users, how responses to those requests are interpreted, and which requests should be requested or analyzed in specific situations. Examples of ID verification rules (180) can include some or all of the following without limitation: knowledge-based authentication (for example, a combination of question and answer), a cross-channel comparison (for example, when two channels different channels, as a primary channel for customers who have their own GUI and a secondary channel represented by a trusted application on a linked device, so that signatures associated with the two different channels are compared, for example, to certify an absolute IP location or relative to one channel compared to the IP location of the other channel), out-of-band authentication (for example, which can send an SMS or email verification message regardless of communication with the user's digital banking device), a known fraud exchange assessment (for example, a fraud exchange known as known fraud in a government ID), a Pll speed analysis (for example example, one out of the ordinary usage pattern for Pll information), a transaction speed analysis for a specific user (or compared to a normal user), transaction data analysis, a biometric analysis (for example, impression analysis digital, voice analysis, facial recognition, etc.), Pll associated with the device based on carrier adhesion (for example, accessing data sources associated with the existing carrier to corroborate the customer supplied Pll), IDs or other suspicious Pll or known (for example, based on fraud analysis systems or infrastructures maintained), and device reputation (for example, when the device was previously associated with one or more high-risk transactions or the duration of the device was associated with the user) , as well as several other rules of
Petition 870190079542, of 16/08/2019, p. 120/148
47/61 proper identification verification. Customer-specific rules (186) can define which of these techniques will be used in analyzing transactions.
[073] As illustrated, a consumer-specific data set (181) can also be maintained by the partnership system (160). Specifically, the consumer specific data set (181) can store a customer key table (182), where the digital IDs (183) of specific consumers are kept and where the specific consumer GUIDs associated with those digital IDs are kept after its generation and supply to the corresponding customer's system (130). In addition, historical transaction data (184) associated with consumers can be maintained and applied to future fraud assessments, where appropriate. In some cases, historical transaction data (184) can be explored and / or analyzed to determine risks across all customers and for all consumers. The history of information can, for example, be anonymized and used to assess fraudulent standards, which can then be incorporated into fraud assessment rules and standards (185) for future fraudulent assessments.
[074] Although portions of the software elements illustrated in Figure 1 are shown as individual modules that implement various features and functionality through various objects, methods, or other processes, the software may instead include a series of sub-modules, services third parties, components, libraries and others, as appropriate. Conversely, the characteristics and functionality of various components can be combined into individual components as appropriate.
[075] Figure 2 is an example diagram of a simplified system (200) for providing a digital ID network. The illustration represents an example of a set of components that perform operations similar to those described in Figure 1, particularly in view of banking and online activity.
Petition 870190079542, of 16/08/2019, p. 121/148
48/61 [076] Banking activity platform (202), mobile application (204) and online merchant platform represent three components of the digital ID network external to the backend partnership system (201), as a partnership system (160) illustrated in Figure 1. Banking platforms (202) represent a set of banking solutions and operations associated with a plurality of banking systems, where banking platforms (202) are associated and perform standard banking transactions for users registered on these banking platforms (202) . The solution in this disclosure allows a single main digital ID to be used through the plurality of banking activity platforms (202) as described in this application, where each of the specific customers (for example, banking activity platform (202), platform online merchant (206)) are associated with a secondary digital ID associated with the individual primary digital ID for a specific consumer. For example, a bank-specific secondary digital ID can be used by a specific banking activity platform, while another merchant-specific secondary digital ID can be used by a specific merchant (206). The mobile application (204) represents the trusted mobile application (for example, trusted mobile application (105)) used as the hub for consumer linking operations and additional authentication performed by the system (200). The online merchant platform (206) represents, similar to the banking activity platforms (202), one or more merchant platforms that integrate the digital ID network and that allow transactions to be carried out through the use of the individual digital ID, while providing security and improved authentication techniques.
[077] Component information (202, 204, 206) enters the system through an API 210 integration gateway, where requests and responses are received and other interactions are sent from the system.
Petition 870190079542, of 16/08/2019, p. 122/148
49/61 partnership (201). The integration gateway (210) may have the ability to broker and manage trusting interactions between banking activity platforms (202) and online merchant platforms (206) with the backend systems used by the partnership system (201), including each of the individual components used in the ID verification and fraud analysis processes.
[078] A set of mobile services (212) is associated with the partnership system (201): the cell ID verification module (214) and the device linking module (216). The mobile verification module (214) has the ability and functionality to verify the identity of a specific consumer, based on the Pll as provided in the registry. The mobile verification module (214) can verify the Pll based on one or more internal and / or external databases, including those maintained by the partner system's manager or affiliate system (201). The device link module (216) can establish and provide a physical link (for example, a key) associated with the device, where the link is shared between a private user and its associated mobile device, as described in this application, for authentication through the partnership system (201). Once the link is established, the mobile device and information associated with it can be used to evaluate specific transactions. In addition, a secure channel between the partnering system (201) and the mobile application (204) installed on the mobile device can be used to request additional information and / or data for higher levels of authentication.
[079] Fraud services (218) can perform analysis of specific transactions in view of specific transaction data, recent and related transactions carried out by the specific consumer associated with a similarly or related transaction and / or consumer, information about a channel on which the operation was requested, compared
Petition 870190079542, of 16/08/2019, p. 123/148
50/61 to the information associated with the mobile device, as well as others. An ID scoring module (220) uses link and switch technology through high quality data sources to assess and approve digital ID across systems, allowing for risk-free authentication without conflict, when available, and requesting authentication additional when potential problems or fraud are identified. The speed analysis module (222) detects suspicious and potentially fraudulent activity through financial institutions that can be indicative of fraud, including an analysis related to the number of attempted transactions, compared to normal user activity or compared to other users and consumers. Pattern analysis related to fraud can be used on all consumer interactions with banking and merchant platforms as available to assess the frequency of transactions and / or the number of transactions associated with digital ID. The activity tracking module (224) leverages real-time activity and device signature information (for example, which may include specific features about the device itself, including OS versions, jailbreak status, specific applications installed, information about hardware, etc.) to detect suspicious behavior, including information about the location of the mobile device in relation to a location where the transaction is requested. In some cases, this may be based on a comparison of IP addresses, absolute and / or relative locations between the location of the transaction and the location of the device, as well as the location of other recent purchases and / or activities relating to the location of a requested transaction. Alternatively, a current location associated with the attempted transaction can be compared to a normal and / or expected location of the device, so that unexpected locations can be provided with further examination and analysis. The behavior analysis module (226) can allow the
Petition 870190079542, of 16/08/2019, p. 124/148
51/61 machine and / or self-learning algorithms study the normal or usual characteristics of a specific consumer or group of consumers, and compare certain activities in real time to those expected characteristics to determine if potential fraudulent activity is taking place based on the moment , size, location, among other characteristics, of specific transactions.
[080] The scoring service (228) takes actions to determine whether additional authorization is required by the customer's systems (for example, online banking platforms (202) or merchant platforms (206)), based on predefined requirements and / or whether identifying fraud or potential problems with ID checks requires additional consideration. The rules engine (230) can provide workflow capability for the partnering system (201), where information about the data source can be fed into customer-specific rules to determine analysis results and identify next ones steps, including requesting additional information or verifications from the mobile app (204) before additional transactions are approved.
[081] The data feed (208) represents a data feed that provides data from a financial institution to the digital ID network and partnership system (201) on a predetermined and / or ongoing schedule. The information received can be used to update the assessments of the partnership system (201) and its components, to update specific rules, and to keep the system current (201). The data ingest module (234) of the data services (232) can receive and update new data for the digital ID network, while the digital ID market (236) provides an on-demand view of identity information associated with a or more consumers. The digital ID market (236) can be used to create IDs
Petition 870190079542, of 16/08/2019, p. 125/148
52/61 for new registrations, including a “registration system”, which can include activity information, device-specific information, consumer-associated PLL information, historical transaction data and other information. Existing data sources can be leveraged to build the existing digital ID market (236), so that existing consumer information can be incorporated into your digital ID to provide immediate advanced analysis and analysis by registration.
[082] Figure 3 is a flow chart of an example registration operation from the perspective of the partnership system, such as the partnership system (160). For clarity of presentation, the following description generally describes the method (300) in the context of the system (100) illustrated in Figure 1. However, it will be understood that the method (300) can be performed, for example, by any other suitable system, environment, software and hardware, or a combination of systems, environments, software and hardware as appropriate.
[083] In (305), a request to register a user with the digital ID network is identified, where the order is provided from a first customer system within the plurality of customer systems included in the digital ID network. In addition, the specific user associated with the registration request may already have an existing trust relationship with the customer's first system.
[084] In (310), a set of personally identifiable information is obtained associated with the specific user. The PLL can be passed from the first entity, although in other cases, the information can be provided directly by the specific user. In (315), an ID verification and fraud risk assessment analysis for the specific user is performed based on the obtained PLL.
[085] In (320), a determination is made as if the analysis
Petition 870190079542, of 16/08/2019, p. 126/148
53/61 was satisfied. In some cases, ID verification satisfaction and fraud risk assessment may be based on absolute or relative scores being generated by the partnership system based on available information. Once the score is generated, satisfaction can then be based on a determination of whether that score exceeds a threshold value. In some cases, the score generated may be a score based on trust or a combination of scores, where the relative confidence of the ID check represents a first score and the fraud risk assessment provides a second score. In such cases, if both scores or a combination of the scores exceeds a minimum threshold value, then the registration process continues at (330). Other assessments and criteria suitable for satisfaction can be used in other cases. However, if the analysis is not satisfied, method (300) changes to (325) where the registration request with the digital ID network is rejected due to the system being unable to verify the Pll ID of the specific user or due to a certain potential for fraud based on the analysis being too high for inclusion in the federated network.
[086] In (330), a unique digital ID is generated for the specific user for use within the digital ID network, the digital ID exclusively representing the specific user for the partnering system. Additionally, a second unique digital ID specific to the client is generated, where the second digital ID is used by the client in reference to the specific user during interactions between the client and the partnering system, ensuring that the client's system and / or information user's customer specifics are compromised, the primary digital ID of the specific user that is used across the digital network and the partner system would not be compromised. In some cases, the customer through which registration occurs may initially be provided with a second, or secondary, digital ID associated specifically with the customer's interactions and used in interactions with the partnering system. In
Petition 870190079542, of 16/08/2019, p. 127/148
54/61 other cases, the secondary digital ID can be generated later, as (350) below.
[087] In (335), an image is generated that represents the unique digital ID of the specific user, and the generated image is transmitted to the first presentation of the entity or interface associated with the interactions with the specific user. The broadcast may include instructions for the specific user to capture a photo or submit the image through a trusted mobile application associated with the digital ID network and the partnering system. In some cases, the image may have an alphanumeric digital ID (or the native format of the digital ID unchanged). In other cases, the digital ID can be encoded in an image (for example, in a QR code) and used as a replacement for the digital ID itself. In still other cases, the digital ID can be encoded without an image and other coded presentations and can be used in a different way to authenticate the user on the user's cell phone or other device.
[088] In (340), a determination is made as if a photo of the generated image was received through the trusted mobile application running on the mobile device associated with the specific user. If no photo is received, or if the photo does not match the generated image, the method (300) changes to (325), where the order is rejected. If, instead, the photo is received and is compatible or otherwise corresponds to the generated image and / or the unique encoded identifier, the mobile device on which the trusted mobile application is installed and running can be confirmed and linked to the specific digital ID of the specific user at (345), when the trusted mobile device and mobile app can be used for future ID checks and fraud detection procedures for interactions within the digital ID network involving the unique digital ID of the specific user. In addition, the unique digital ID can be submitted through interfaces and applications associated with
Petition 870190079542, of 16/08/2019, p. 128/148
55/61 different customer systems in addition to the first customer system, where these customer systems are registered with the digital ID network.
[089] In addition to linking the mobile device to the unique digital ID, at (350), the partnership system can generate a first unique identifier (for example, a GUID) for use by the customer's first system when interacting with the specific user , where the first unique identifier is different from the digital ID. The first unique identifier can be used by the customer's first system to identify the specific user associated with the digital ID, thus avoiding sharing the digital ID across system boundaries when not needed. Each customer system with a specific user relationship can receive or generate a new unique identifier that can be used instead of the other Pll with the partnership system for future transactions, limiting the possible interception vectors to the digital ID information within the partnership system associated with the user.
[090] Figure 4 is a flow chart of an example operation to perform additional authentication operations between the partnership system and a trusted mobile application from the perspective of the partnership system, such as the partnership system (160). For clarity of presentation, the following description generally describes the method (400) in the context of the system (100) illustrated in Figure 1. However, it will be understood that the method (400) can be performed, for example, by any other suitable system, environment, software and hardware, or a combination of systems, environments, software and hardware as appropriate.
[091] In (405), information associated with a request to perform a specific transaction associated with a digital ID is received from a customer's system. The information received may include a specific user ID associated with the request, the type of transaction to be carried out and, in some cases, risk assessment strategy
Petition 870190079542, of 16/08/2019, p. 129/148
56/61 customer specific. In other cases, customer-specific risk assessment rules can be stored in the partnering system, and can be tied to specific types of transactions being requested. Transactions can include logins to the customer's system, standard transactions (for example, account balance reviews, account information updates, purchases under a predefined threshold amount, etc.), relatively high risk transactions (for example , a funds transfer, a loan request, purchases that exceed a predefined limit, etc.), or other types of transactions. Depending on the type of transaction, different risk assessment strategies can be carried out. In addition, one or more different fraud risk analyzes can be performed based on available information associated with the specific user, recent transactions associated with the user, and other relevant information, including information associated with the connected mobile device and linked to the user's digital ID specific (for example, a mobile device location in relation to the transaction location).
[092] In (410), the risk assessment strategy is carried out based on the information received. In some cases, the risk assessment strategy may require an additional authentication operation to be performed. In other cases, fraud assessment based on the information received may trigger a requirement for additional authentication information prior to authorization of the requested transaction. In some cases, the risk assessment strategy is implicitly determined from the information received, or from a connection to the type of transaction identified in the information received. In some cases, information received can be assessed for fraud without explicit or implicit notice, such as by comparing the information received (and other information available about the specific user and / or mobile device) to one or more standards or rules related to fraud .
Petition 870190079542, of 16/08/2019, p. 130/148
57/61 [093] In (415), a determination is made if additional authentication operations are necessary based on the risk assessment strategy and / or the fraud risk analysis. If not, the process can continue at (420), where a transaction-free authentication of the transaction request can be performed and passed back to the customer system associated with the transaction without requiring additional information or additional interactions with the user to authenticate the transaction. transaction. If, however, an additional authentication operation is determined to be necessary, method (400) continues to (425), where a secure channel is established with the mobile device's trusted mobile application linked to the specific user's digital ID. The secure channel can be based on encrypted or otherwise protected communications between the partner system and the trusted mobile application. Any suitable way of creating the secure channel can be used.
[094] In (430), the additional authentication operations required by the risk assessment strategy and / or the fraud risk analysis are carried out by preparing and sending requests in real time to the user through the trusted mobile application. Real-time requests can include any suitable format, including a request for user biometric data (for example, a fingerprint, a speech recognition process, a facial recognition process, etc.), a request for a response to a question with a correct answer known to the user and unlikely to be known to an attacker or imposter (for example, the amount of a current car payment or a previous address), a push notification that requires a second mobile device authentication factor, as well as other types of interactions and authentication operations.
[095] In (435), a determination is made as if a response was received from the user for the requested authentication operation
Petition 870190079542, of 16/08/2019, p. 131/148
58/61 through the trusted mobile app. In some cases, the time for a response may be limited to a certain time limit (for example, five (5) minutes from the initial request) before the transaction is rejected. If no response was received, at (440) an indication of the failure of the authentication operation can be provided to the customer's system. If a response has been received, method (400) continues at (445), where a determination is made as if the response received met the requirements for additional authentication operation to authorize the transaction. If the response does not satisfy the additional authentication operation, method (400) resumes to (440) and indicates to the client's system that the additional authentication operation has failed. The failure to satisfy the additional authentication operation may be based on an explicit indication from the trusted mobile application that the user was not associated with the original transaction request, a failure in the biometric response, a failure in answering a question based on in knowledge or other similar response that failed based on an evaluation of the response to the authentication operation. If, however, the response satisfies the assessment of the additional authentication operation by validating the user's identification and / or confirming that the transaction request was not fraudulent, the results of the success of the additional authentication operation can be sent to the customer's system at (450), where these results may result in a pending transaction authorization in the customer's system.
[096] The previous figures and accompanying description illustrate example systems, processes and techniques implementable by computer. Although the systems and processes illustrated contemplate the use, implementation or execution of any suitable technique to perform these and other tasks, it will be understood that these systems and processes are for illustration purposes only and that the described or similar techniques can be performed at any time appropriate, including simultaneously, individually or
Petition 870190079542, of 16/08/2019, p. 132/148
59/61 in combination, or performed by alternative components or systems. In addition, many of the operations in these processes can occur simultaneously, at the same time and / or in orders other than those shown. In addition, the illustrated systems can use processes with additional operations, fewer operations and / or different operations, as long as the methods remain appropriate.
[097] Several potential alternative and additional features can be considered with the illustrations and descriptions in this application. In other words, although this disclosure has been described in terms of certain and generally associated achievements, methods, changes and permutations of those achievements and methods will be evident to those skilled in the art.
[098] In some cases, the trust associated with a specific device and its underlying consumer can be used to approve consumer actions in addition to customer-related actions. Whenever a customer considers that a transaction carries high risk and / or liability, the customer may wish to carry out an increase in confidence to mitigate the risk. Examples of these may include changes of address, cash handling operations, and others. Throughout the trust and partnership network, the network itself can take advantage of the trust to introduce members of the trust network to customers (for example, banking providers, retail providers), with the purpose of authenticating not only those members , but providing trusted user information through the digital trust network to ensure that users do not have to manually enter this information again where it can possibly be intercepted. In other cases, the forms used to register with other customers may be pre-filled, or this information may be passed on without the need for specific submissions through III by the consumer. In this respect, too, the use of the trust relationship may allow non-repudiation to be considered
Petition 870190079542, of 16/08/2019, p. 133/148
60/61 as a user authentication factor for other clients associated with the digital trust network.
[099] In general, the consumer digital trust relationship for the device, and between the consumer / device and the digital trust network allows a plurality of actions to be taken within the system. One feature is digital ID registration, where consumers already associated with the digital trust network can authorize, through the trusted mobile application, website integration, application integration for devices and application integration of mobile hub based on the relationship of the trusted device. In addition, additional security can be provided for customer systems, which allow these customers to provide consumers with conflict-free access and logins to websites, mobile apps and mobile hub apps, when appropriate and when the mobile app of trust is used or associated with interactions, thus providing the necessary information to confirm the trust relationship.
[100] In addition, the trust relationship can enable specific customers to take advantage of the capabilities of digital trust networks and trusted mobile applications by mitigating risk in high-risk transactions as defined by the customer. Specifically, intensification of approval and / or authentication based on context can be used to require manual or interactive confirmation, determinations and / or authentications for transactions and operations that may include additional risk. For example, payment approvals made through websites, mobile apps and / or other channels can be associated with additional interactions or security requests, which can be sent or distributed via the trusted mobile app. As the user / consumer is trusted to be associated with the mobile device and the trusted mobile application, authentications or authorizations for transactions can be carried out via messages
Petition 870190079542, of 16/08/2019, p. 134/148
61/61 or distributed interactions that interact with the trusted mobile app.
[101] In other cases, the consumer may be able to perform device management operations through the trusted mobile application, as well as interact with the customer's functionality and support capabilities. Using the trusted mobile app, consumers may be able to perform customer support activities for device management, including unregistering the device, suspending the device, or searching for the digital IDs associated with the partnering system. In addition, Uls and interactions can be made available to the consumer to search for transactions carried out across the digital trust network on demand, allowing the consumer to determine and confirm that the activity carried out using the digital trust identity is in compliance with activities known to the user.
[102] Consequently, the above description of exemplary achievements does not define or restrict this disclosure. Other changes, substitutions and alterations are also possible without departing from the spirit and scope of this disclosure.

权利要求:
Claims (21)
[1]
Claims
1. SYSTEM, which comprises a digital trust system that manages a digital ID network, characterized by the fact that the digital trust system comprises:
at least one processor; and a non-transitory computer-readable media storage instruction executable by at least one processor, instructions instructing at least one processor to:
identify a request to trust a specific user, the specific user associated with a first trust relationship with a first entity, the first entity associated with the digital ID network;
obtain a set of personally identifiable information (Pll) associated with the specific user through the first entity;
perform an identity verification (IDV) and analysis of the fraud risk assessment of the specific user based on the set of Pll obtained; and in response to satisfying IDV and fraud risk assessment analysis:
transmit instructions to the specific user to verify the identity of the specific user through a trusted mobile application installed on a mobile device associated with the specific user; and in response to verifying the identity of the specific user via the trusted mobile application installed on the mobile device, link the mobile device to the specific user within the digital ID network, where the mobile device is associated with a unique set of device information and the unique set of device information is incorporated into a generated digital ID associated with the specific user, where the generated digital ID is available for use by a plurality of entities registered on the digital ID network for authentication of the specific user.
Petition 870190079542, of 16/08/2019, p. 136/148
[2]
2/8
2. SYSTEM, according to claim 1, characterized by the fact that the generated digital ID associated with the specific user comprises a unique key created to associate the specific user's PLL, the mobile device associated with the specific user and the activities associated with the user.
[3]
3. SYSTEM, according to claim 1, characterized by the fact that the instructions instruct at least one processor to, in response to satisfy the IDV and the fraud risk assessment analysis, generate a unique code associated with the specific user, in which the transmission of instructions to the specific user to verify the identity of the specific user through the trusted mobile application comprises the transmission of the unique code generated to an interface of the first entity with instructions for the specific user, and where the identity of the specific user is verified through the trusted mobile app by checking the unique code transmitted with the instructions for the specific user.
[4]
4. SYSTEM, according to claim 3, characterized by the fact that generating the unique code comprises generating an image that encodes the unique code associated with the specific user, and that transmitting the unique code to the interface of the first entity comprises transmitting the image generated for the interface of the first entity, in which the instructions for the specific user to verify the identity of the specific user through the trusted mobile application includes instructions for capturing the image transmitted through the trusted mobile application, and in which to verify the identity of the specific user understands to confirm that the image captured by the trusted mobile application corresponds to the generated image that encodes the unique code associated with the specific user.
[5]
5. SYSTEM, according to claim 1, characterized by the fact that the first trust relationship between the first entity and the specific user is based on a predefined record and user authentication
Petition 870190079542, of 16/08/2019, p. 137/148
3/8 specific by the first entity.
[6]
6. SYSTEM, according to claim 1, characterized by the fact that the fraud risk assessment of the specific user includes at least one among a knowledge-based authentication, a cross-channel comparison, an out-of-band authentication, an exchange assessment of known fraud, an analysis of the speed of use of Pll, an analysis of the transaction speed for the specific user, an analysis of transaction data, a biometric analysis, a comparison of the Pll of the specific user against a set of known Pll associated with a risk of fraud and a device reputation analysis.
[7]
7. SYSTEM, according to claim 1, characterized by the fact that each entity of the plurality of entities is associated with a set of entity-specific authentication rules, each set of entity-specific authentication rules identifies a set of transactions for a specific entity and identifies a level of authentication required by users associated with the transactions.
[8]
8. SYSTEM, according to claim 7, characterized by the fact that at least some of the transactions for a specific entity require at least an additional first authentication operation for users associated with the transactions, in which at least an additional first authentication operation comprises a first authentication request to be transmitted from the digital trust system to a specific mobile device previously linked to the digital ID associated with the specific transaction, the trust system still configured to transmit the first authentication request to the installed trust mobile application on the specific mobile device, where the first authentication request is submitted through the trusted mobile application.
[9]
9. SYSTEM, according to claim 8, characterized
Petition 870190079542, of 16/08/2019, p. 138/148
4/8 because the first additional authentication request comprises a request for biometric entry of the user associated with the digital ID through the trusted mobile application.
[10]
10. SYSTEM, according to claim 8, characterized by the fact that the first additional authentication request comprises a request for a response through the user's input for an authentication challenge.
[11]
11. SYSTEM, according to claim 8, characterized by the fact that the instructions instruct at least one processor to:
receive a response to the first authentication request transmitted from the trusted mobile application installed on the specific mobile device;
validate the response received;
in response to a valid response to the first authentication request, authorize the transaction; and in response to an invalid response to the first authentication request, deny authorization for the transaction.
[12]
12. SYSTEM, according to claim 8, characterized by the fact that a fraud detection assessment is performed on each requested transaction associated with the digital ID, in which the fraud detection assessment is performed for each user's transaction request when associated with the digital ID.
[13]
13. SYSTEM, according to claim 12, characterized by the fact that the response of the potential fraud detection based on the fraud detection assessment, makes at least one additional second authentication request, in which at least one second authentication request additional comprises a second authentication request to be transmitted from the digital trust system to a device
Petition 870190079542, of 16/08/2019, p. 139/148
5/8 specific mobile previously linked to the digital ID associated with the specific transaction, the digital trust system still configured to transmit the second authentication request to the trusted mobile application installed on the specific mobile device, in which the second authentication request is presented through the trusted mobile app.
[14]
14. SYSTEM, according to claim 13, characterized by the fact that at least a second additional authentication request associated with the detection of potential fraud is carried out without a determination that the first additional authentication request is necessary.
[15]
15. Non-transitory computer readable medium, which stores computer-readable instructions executable by a computer, characterized in that the instructions, when executed, are configured to:
identify a request to trust a specific user, the specific user associated with a first trust relationship with a first entity, the first entity associated with a digital ID network;
obtain a set of personally identifiable information (PH) associated with the specific user through the first entity;
perform an identity verification (IDV) and analysis of the fraud risk assessment of the specific user based on the set of Pll obtained; and in response to satisfying IDV and fraud risk assessment analysis:
transmit instructions to the specific user to verify the identity of the specific user through a trusted mobile application installed on a mobile device associated with the specific user; and in response to verifying the identity of the specific user via the trusted mobile app installed on the mobile device, link
Petition 870190079542, of 16/08/2019, p. 140/148
6/8 the mobile device to the specific user within the digital ID network, where the mobile device is associated with a unique set of device information and the unique set of device information is embedded in a generated digital ID associated with the specific user , where the generated digital ID is available for use by a plurality of entities registered in the digital ID network for specific user authentication.
[16]
16. LEGIBLE MEDIA BY COMPUTER, according to claim 15, characterized by the fact that the generated digital ID associated with the specific user comprises a unique key created to associate the PLL of the specific user, the mobile device associated with the specific user and the activities associated with the user.
[17]
17. LEGIBLE MEANS BY COMPUTER, according to claim 15, characterized by the fact that the instructions, when executed, configured to, in response to satisfy the IDV and the fraud risk assessment analysis, generate a unique code associated with the specific user , in which the transmission of instructions to the specific user to verify the identity of the specific user through the trusted mobile application comprises the transmission of the unique code generated to an interface of the first entity with instructions for the specific user, and in which the identity of the specific user is verified through the trusted mobile app by verifying the unique code transmitted with the instructions for the specific user, and in which generating the unique code comprises generating an image that encodes the unique code associated with the specific user, and being that transmitting the code unique to the interface of the first entity comprises transmitting the generated image to the interface of the first the entity, in which the instructions for the specific user to verify the identity of the specific user through the trusted mobile application includes instructions for capturing the image transmitted through the trusted mobile application, and in which to verify the identity of the user
Petition 870190079542, of 16/08/2019, p. 141/148
Specific 7/8 comprises confirming that the image captured by the trusted mobile application corresponds to the image generated that encodes the unique code associated with the specific user.
[18]
18. COMPUTERIZED METHOD, performed by one or more processors, characterized by the fact that the method comprises:
identify a request to trust a specific user, the specific user associated with a first trust relationship with a first entity, the first entity associated with a digital ID network;
obtain a set of personally identifiable information (Pll) associated with the specific user through the first entity;
perform an identity verification (IDV) and analysis of the fraud risk assessment of the specific user based on the set of Pll obtained; and in response to satisfying IDV and fraud risk assessment analysis:
transmit instructions to the specific user to verify the identity of the specific user through a trusted mobile application installed on a mobile device associated with the specific user; and in response to verifying the identity of the specific user via the trusted mobile application installed on the mobile device, linking the mobile device to the specific user within the digital ID network, where the mobile device is associated with a unique set of device information and the unique set of device information is incorporated into a generated digital ID associated with the specific user, where the generated digital ID is available for use by a plurality of entities registered on the digital ID network for authentication of the specific user.
[19]
19. METHOD, according to claim 18, characterized by the fact that each entity of the plurality of entities is associated with a set of entity-specific authentication rules, each set of
Petition 870190079542, of 16/08/2019, p. 142/148
8/8 entity-specific authentication rules identifies a set of transactions for a specific entity and identifies a level of authentication required by users associated with the transactions, where at least some of the transactions for a specific entity require at least a first authentication operation additional for users associated with transactions, in which at least an additional first authentication operation comprises a first authentication request to be transmitted from the digital trust system to a specific mobile device previously linked to the digital ID associated with the specific transaction, the system Trusted yet configured to transmit the first authentication request to the trusted mobile application installed on the specific mobile device, where the first authentication request is submitted through the trusted mobile application.
[20]
20. METHOD, according to claim 19, characterized by the fact that the first additional authentication request comprises a request for the biometric entry of the user associated with the digital ID through the trusted mobile application or a request for a response through the user's entry to an authentication challenge.
[21]
21. METHOD, according to claim 19, characterized by the fact that the method still comprises:
receive a response to the first authentication request transmitted from the trusted mobile application installed on the specific mobile device;
validate the response received;
in response to a valid response to the first authentication request, authorize the transaction; and in response to an invalid response to the first authentication request, deny authorization for the transaction.

类似技术:

---

公开号 | 公开日 | 专利标题

---

US11095643B2|2021-08-17|Universal digital identity authentication service

---

US11032269B2|2021-06-08|Method and system for establishing trusted communication using a security device

---

US10430578B2|2019-10-01|Service channel authentication token

---

CN105378790B|2020-06-12|Risk assessment using social networking data

---

US11063944B2|2021-07-13|Out-of-band authentication based on secure channel to trusted execution environment on client device

---

US11250530B1|2022-02-15|Method and system for consumer based access control for identity information

---

KR20190039077A|2019-04-10|Biometric identification and verification between IoT devices and applications

---

US9548997B2|2017-01-17|Service channel authentication processing hub

---

US10032168B2|2018-07-24|Secure validation of financial transactions

---

US20140089189A1|2014-03-27|System, method, and apparatus to evaluate transaction security risk

---

JP2017519412A|2017-07-13|Enhanced security for authentication device registration

---

US20110145565A1|2011-06-16|Federated authentication for mailbox replication

---

US11227354B2|2022-01-18|Integration of workflow with digital ID

---

US20210014064A1|2021-01-14|Method and apparatus for managing user authentication in a blockchain network

---

US11159321B2|2021-10-26|Digital notarization using a biometric identification service

---

US9239936B2|2016-01-19|System, method, and apparatus to mitigaterisk of compromised privacy

---

US10819526B2|2020-10-27|Identity-based certificate authority system architecture

---

Ahmad et al.2019|Enhancing the Authentication Mechanism of Social Media Websites using Face Detection

同族专利:

---

公开号 | 公开日

---

CA3053957A1|2018-08-23|

---

WO2018151822A1|2018-08-23|

---

EP3937456A4|2022-01-12|

---

EP3583758B1|2021-04-07|

---

US20200403992A1|2020-12-24|

---

EP3583758A1|2019-12-25|

---

US20210336955A1|2021-10-28|

---

EP3937456A1|2022-01-12|

---

EP3583758A4|2020-01-29|

---

AU2018222744A1|2019-07-25|

---

US11095643B2|2021-08-17|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

WO2002095589A1|2001-05-17|2002-11-28|Identix Incorporated|Mobile identity verification|

---

CA2541824A1|2003-10-08|2005-04-14|Stephan J. Engberg|Method and system for establishing a communication using privacy enhancing techniques|

---

US8028329B2|2005-06-13|2011-09-27|Iamsecureonline, Inc.|Proxy authentication network|

---

US20070265984A1|2006-04-24|2007-11-15|Prakash Santhana|Financial transaction using mobile devices|

---

US20100125635A1|2008-11-17|2010-05-20|Vadim Axelrod|User authentication using alternative communication channels|

---

WO2010064128A2|2008-12-03|2010-06-10|Entersect Mobile Cc|Secure transaction authentication|

---

US7685629B1|2009-08-05|2010-03-23|Daon Holdings Limited|Methods and systems for authenticating users|

---

US8935797B1|2010-02-25|2015-01-13|American Express Travel Related Services Company, Inc.|System and method for online data processing|

---

US9544143B2|2010-03-03|2017-01-10|Duo Security, Inc.|System and method of notifying mobile devices to complete transactions|

---

US20120036569A1|2010-04-05|2012-02-09|Andrew Cottrell|Securing portable executable modules|

---

US9607336B1|2011-06-16|2017-03-28|Consumerinfo.Com, Inc.|Providing credit inquiry alerts|

---

US20130055346A1|2011-08-25|2013-02-28|Alcatel-Lucent Usa Inc.|Event Driven Multi-Factor Authentications For Internet Transactions|

---

US9202026B1|2011-11-03|2015-12-01|Robert B Reeves|Managing real time access management to personal information|

---

US20130317993A1|2012-05-25|2013-11-28|24/7 Customer, Inc.|Method and apparatus for linking user sessions and establishing identity across channels|

---

US9130929B2|2013-03-15|2015-09-08|Aol Inc.|Systems and methods for using imaging to authenticate online users|

---

US9721147B1|2013-05-23|2017-08-01|Consumerinfo.Com, Inc.|Digital identity|

---

ES2642441T3|2014-07-07|2017-11-16|Finpin Technologies Gmbh|Procedure and system to authenticate a user|

---

EP3065435A4|2015-01-05|2017-04-19|EBIID, Products & Solutions, S.L.|Method for generating a digital identity for a user of a mobile device, digital user identity, and authentication method using said digital user identity|

---

US20160380774A1|2015-03-26|2016-12-29|Assa Abloy Ab|Virtual credentials and licenses|

---

US9767309B1|2015-11-23|2017-09-19|Experian Information Solutions, Inc.|Access control system for implementing access restrictions of regulated database records while identifying and providing indicators of regulated database records matching validation criteria|

---

US20170213211A1|2016-01-25|2017-07-27|Apple Inc.|Document importation into secure element|

---

US10348699B2|2016-02-11|2019-07-09|Evident ID, Inc.|Identity binding systems and methods in a personal data store in an online trust system|

---

US20190342096A1|2016-02-11|2019-11-07|Evident ID, Inc.|Online identity and credential verification systems and methods protecting user data|

---

US10210386B2|2016-03-31|2019-02-19|Facebook, Inc.|Storing identification data as virtual personally identifiable information|

---

US10210518B2|2016-04-13|2019-02-19|Abdullah Abdulaziz I. Alnajem|Risk-link authentication for optimizing decisions of multi-factor authentications|

---

US20170359313A1|2016-06-08|2017-12-14|Facebook, Inc.|Methods and Systems for Data Anonymization at a Proxy Server|

---

CA3053957A1|2017-02-17|2018-08-23|Richard Huffman|Universal digital identity authentication service|

---

PL3662634T3|2017-09-18|2021-12-06|Mastercard International Incorporated|Systems and methods for managing digital identities associated with mobile devices|

---

US20190166118A1|2017-11-29|2019-05-30|Jpmorgan Chase Bank, N.A.|Secure multifactor authentication with push authentication|

---

US10965673B2|2018-05-11|2021-03-30|Civic Technologies, Inc.|User ID codes for online verification|

---

IL261679D0|2018-09-06|2018-10-31|Acuant Inc|System and method for management of digital id|

---

US11227354B2|2019-05-20|2022-01-18|The Toronto-Dominion Bank|Integration of workflow with digital ID|

---

US10922631B1|2019-08-04|2021-02-16|Acceptto Corporation|System and method for secure touchless authentication of user identity|US9412123B2|2003-07-01|2016-08-09|The 41St Parameter, Inc.|Keystroke analysis|

---

US10999298B2|2004-03-02|2021-05-04|The 41St Parameter, Inc.|Method and system for identifying users and detecting fraud by use of the internet|

---

US8151327B2|2006-03-31|2012-04-03|The 41St Parameter, Inc.|Systems and methods for detection of session tampering and fraud prevention|

---

US8312033B1|2008-06-26|2012-11-13|Experian Marketing Solutions, Inc.|Systems and methods for providing an integrated identifier|

---

US9607336B1|2011-06-16|2017-03-28|Consumerinfo.Com, Inc.|Providing credit inquiry alerts|

---

US9633201B1|2012-03-01|2017-04-25|The 41St Parameter, Inc.|Methods and systems for fraud containment|

---

US9521551B2|2012-03-22|2016-12-13|The 41St Parameter, Inc.|Methods and systems for persistent cross-application mobile device identification|

---

WO2014078569A1|2012-11-14|2014-05-22|The 41St Parameter, Inc.|Systems and methods of global identification|

---

US10664936B2|2013-03-15|2020-05-26|Csidentity Corporation|Authentication systems and methods for on-demand products|

---

US9721147B1|2013-05-23|2017-08-01|Consumerinfo.Com, Inc.|Digital identity|

---

US10902327B1|2013-08-30|2021-01-26|The 41St Parameter, Inc.|System and method for device identification and uniqueness|

---

US10091312B1|2014-10-14|2018-10-02|The 41St Parameter, Inc.|Data structures for intelligently resolving deterministic and probabilistic device identifiers to device profiles and/or groups|

---

CA3053957A1|2017-02-17|2018-08-23|Richard Huffman|Universal digital identity authentication service|

---

EP3759630A4|2018-03-02|2021-11-24|Blocksafe Technologies, Inc.|Systems and methods for controlling access to a blockchain|

---

EP3627363A1|2018-09-19|2020-03-25|Vocalink Limited|Information processing system, devices and methods|

---

US11271917B2|2018-10-03|2022-03-08|Tactical Lighting Systems|System security infrastructure facilitating protecting against fraudulent use of individual identity credentials|

---

US11250160B2|2019-08-12|2022-02-15|Bank Of America Corporation|Machine learning based user and third party entity communications|

---

US10992765B2|2019-08-12|2021-04-27|Bank Of America Corporation|Machine learning based third party entity modeling for preemptive user interactions for predictive exposure alerting|

法律状态:
2021-05-11| B15V| Prolongation of time limit allowed|Free format text: TENDO EM VISTA A PORTARIA INPI PR NO 120 DE 16/03/2020, PORTARIA INPI PR NO 161 DE 13/04/2020; PORTARIA INPI PR NO 166 DE 27/04/2020 E PORTARIA INPI PR NO 179 DE 11/05/2020, QUANTO A SUSPENSAO DOS PRAZOS VENCIDOS ENTRE 16/03/2020 A 31/05/2020, E PORTARIA INPI NO 334 DE 24/09/2020, QUANTO AOS PRAZOS VENCIDOS ENTRE 16/09/2020 A 25/09/2020, DEVOLVE-SE O PRAZO NESSE PEDIDO COM RELACAO A SOLICITACAO DO PEDIDO DE EXAME. |

---

2021-10-19| B350| Update of information on the portal [chapter 15.35 patent gazette]|

优先权:

---

申请号 | 申请日 | 专利标题

---

US201762460611P| true| 2017-02-17|2017-02-17|

---

PCT/US2018/000034|WO2018151822A1|2017-02-17|2018-02-16|Universal digital identity authentication service|

---